Distributed computing has become the standard paradigm of computing characterized by a number of computers, called clients and servers, interconnected through a network wherein the logic and the software applications used by one client or server resides on another server. A server computer may provide the application software, the logic, and sometimes even the databases for a number of other servers and clients. The explosive growth of access to the Internet, moreover, has farther contributed to the modern computing paradigm such that in today's computing environment, the network connecting clients and servers is the world wide web. Hypertext transfer protocol (HTTP) is a network protocol of the world wide web (the Web), and Java® is a programming language developed by Sun Microsystems that blossomed and thrived in the mid to late 1990s coincident with the burgeoning expansion of network computer technology and the browser/HTTP technology on the Internet and Intranets in part because Java is independent of the operating system of a computer. Java applications can be written on one computer and transferred over a network, such as the Internet, to any processing device having a Java virtual machine regardless of the hardware or software in the receiving machine, consistent with the Write Once, Run Anywhere philosophy of Java software development. Thus, Java applications can be written on one server and then transferred over the web to multiple clients/servers.
A tutorial of definitions as used in the paradigm of networked computing may be helpful. An application or a client program is a software program used by an end user. For instance, a person entering data to schedule employees' workdays may be using a scheduling client program or application. A person writing a paper may be using a word processing application. A person creating a visual demonstration may be using a presentation application. A tool is a software application environment that enables a software developer to write further applications in a particular computer environment. IBM's VisualAge, Visual J++, Lotus Bean Machine, Semantic Café, etc. are all tools that allow a programmer to write Java applications. A component is software code that can be reused across multiple applications; in other words, a component is standard software that can be pulled off a server and incorporated into new applications using a tool by software developers. For example, a calendar component may be used in several applications such as a scheduling application, a presentation application, a data base application to calculate employee's vacation and pay, etc. Thus, a software developer using tools to write an application can pull a calendar component of the server for insertion into the application.
A JavaBean is a particular kind of component that can be visually manipulated in a tool and meets a standard protocol of Sun Microsystems for the Java programming language. JavaBeans are intended to be relatively coarse-grained business objects such as a generic purchase order or an employee record or a calendar. A JavaBean is defined by two interfaces: (1) the public or home interface containing methods to either create or remove JavaBeans and, in the case of persistent JavaBeans (Entity Beans), to find and instantiate a JavaBean; and (2) the remote interface or JavaBean object which defines the business methods of a JavaBean that can be accessed by a client program. Any interface of a JavaBean is defined by three aspects: (1) attributes; (2) events; and (3) methods. An attribute is supported by public getter and/or setter methods and may be of three kinds: simple; boolean; or indexed, each of which may be bound or constrained. For example, a simple attribute in a spreadsheet tool would be the balance of an account. An example of an indexed attribute in the spreadsheet tool would be the owners of an account, if there were more than one owner. An example of a boolean attribute would be if the balance of the account were greater or less than a particular amount such that a response would be true or false. A bound attribute tells its dependent attributes that it has changed when/after it changes. A constrained attribute notifies its dependent attributes before it changes and the listeners of that constrained attribute have the option to veto the change, called an exception. An example of a bound attribute would be the balance of a bank account. An example of a constrained attribute would be change of ownership of the account. A session object is a JavaBean object that executes on behalf of a single client, can be aware of transactions, can update shared data in an underlying database, but does not represent directly shared data in the database and is relatively short-lived. An entity object provides an object view of data in the database, allows shared access of data in the database from multiple users, and can be long-lived. JavaBeans are distributed across a computer network through a Java Archive (JAR) which is basically a zip file with a manifest file.
Servlets are programs that run on a Web server, acting as a middle layer between a request coming from a Web browser or other HTTP client and databases or applications on the HTTP server. Servlets allow one computer/application to read any data, usually entered in a form on a Web page but which could also come from a Java applet or a custom HTTP client program, across a network. Servlets have a myriad of capabilities, they can look up information, such as details about browser capabilities, cookies, the host name of the requesting client, etc., embedded in a HTTP request; servlets can generate a response to a request by, e.g., talking to a database, executing a remote method invocation or a common object request broker architecture (CORBA), invoking an application, or computing a response directly. In any event, the servlet formats the results and embeds them in an HTML page. A servlet may set appropriate HTTP response parameters by telling a Web browser what type of document is being returned, e.g., HTML, setting cookies and caching parameters, etc. Finally, a servlet can send the document back to the client in text format such as HTML, binary format such as GIF images, or even in a compressed format.
Some client requests can be satisfied by returning the static and/or pre-built documents, and these requests would be handled by the server without invoking servlets. Increasingly so, however, a new Web page needs to be generated for each request. There are a number of reasons why Web pages need to be built “on-the-fly.” The Web page may be based on data submitted by the user such as an on-line shopping cart, or the Web page may be derived from data that changes frequently, such as a news and/or weather. Another cause for dynamically changing Web pages is that an e-commerce site could use a servlet to build a Web page that lists the current price and availability of each item for sale. For example, the initial page at most on-line stores is the same for all visitors, except for a small welcome message giving the visitor's name if it is known.
JavaServer Pages (JSP) refers to Java's implementation that allows a programmer or web developer to mix static (unchanging) HTML features of a web page with dynamically generated content from servlets. JSP allows a programmer to create the two parts of a web page separately such that most of the page may consist of regular HTML passed to the visitor unchanged. Parts that are dynamically generated are marked with special HTML-like tags and mixed into the page.
Web pages programmed in Java on the Internet may contain a list of items each described by a set of visual components, i.e., JavaBeans. A Web page, for example, may display a list of items for purchase, a set of visual components such as a label describing the item, an image depicting the item, perhaps another label for the cost of the item, and a checkbox for a customer to select the item for purchase. JavaServer Pages (also referred to as JSPs) have the capacity to allow a main JSP web page to include one or more other JSPs. These included JavaServer pages are called JSP segments; in the example given above, each item's set of visual components may be grouped together and moved to a JSP segment file. The main JavaServer web page would then include the JSP segment file multiple times, once for each item. Prior to the JavaServer Pages 2.0 specification, JSP segments were called JSP fragments.
The JSP segment may further contain a JavaServer Faces (JSF) visual component. JavaServer Faces technology enables a web developer to build user interfaces for JavaServer applications that assemble reusable user interface components in a page, connect these components to an application data source, and connect client-generated events to server-side event handlers, thus managing the user interfaces on the server, allowing the application developer to focus on application code. JavaServer Faces technology has application program interfaces (APIs) to represent user interface components and manage their state, handle events, validate input, define page navigation, and support internationalization and accessibility. Thus, the JSP segment as described above may further contain a JavaServer Faces visual component bound to a managed JavaBean (or simply bean) having methods for getting and setting the value of the property.
A main JavaServer Page may include a JSP segment multiple times. JavaServer Faces technology and specification dictate that each segment must be contained within a JavaServer Faces subview component. The code 100 shown in the prior art of FIG. 1a of a JavaServer Page includes three instances of a JSP segment: AsubviewOne 110; AsubviewTwo 115; and AsubviewThree 120. Tag libraries contain the code for a set of JavaServer Faces tags, and in a JSP, the Ataglib directive declares the name of a tag library. When a prefix is specified, such as in Ah:inputText, the prefix denotes in which tag library the tag, in this case AinputText is located. One tag library has the universal resource identifier (uri) of Ahttp://Java.sun.com/jsf/core and refers to a core library having a prefix f, in this case, <f:view>135. A core is a JavaServer Faces tag specific to a JavaServer Face component. Another tag library has an uri of Ahttp://Java.sun.com/jsf/html 130 and refers to a JavaServer Faces tag specific to hypertext markup language (html) tag with a prefix h, shown above as <h:form>140. The actual grouping of the user interface components are within a JavaServer Page segment. The code <jsp:include page=segmentjsp/>145 refers to the contained JSP segment in the file named “Segmentjsp” and describes a panel with three input fields: a customer's name; an identifier; and a password. The value of each input field is bound to a property of a JavaServer Faces managed bean named “SegmentSample”. Shown in FIG. 1b is the code of ASegmentjsp and this code is processed three times each time the JavaServer Faces components <f:view> and <h:form> are encountered. Shown in FIG. 1c is the JavaServer Faces managed bean named “SegmentSample” that is declared in the faces-config.xml file of the JavaServer Faces application. The managed bean is implemented by a managed bean class named “codebehind.SegmentSampleClass” that contains getter and setter methods for the properties “name”, “userID”, and “password”; the managed bean class itself is shown in FIG. 2a. 
In the prior art code above, because the main JavaServer Page includes the same JSP segment file multiple times, each JavaServer Faces component instance is bound to the same managed bean property. The property getter and setter methods of the managed bean, however, do not know which segment instance is active when the method is invoked, and as a result, the same property value is displayed in every JSP segment. Because of the shortcomings of the prior art described above, in the SegmentSampleClass class, the index named “_segmentIndex” never changes from its initial state of zero resulting in a web browser display shown in FIG. 2b. There are no known solutions to this problem.
There is thus a need for programmers to have the concept of a record type, where each record type contains a set of fields, each field having characteristics, e.g., length in characters, type such as numeric, and attributes such as protected and highlighted. Multiple instances of records of a single record type can be displayed simultaneously on a 5250 character based display terminal, each with its own data. In converting records and record types to JavaServer Pages/Faces technologies, a record type can be represented by a JavaServer Page segment and each field within the record type can be represented by a JavaServer Faces visual component. Each component can be value bound to properties in a backing bean and a web page may include multiple inclusions of a single record JavaServer Page segment, but no mechanism exists for the determination of which record segment instance is active when a property accessor of the managed bean is invoked by the JavaServer Page/JavaServer Faces runtime.